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Scope 



The present document defines the security architecture of NGN Release 1 . The definition complies with the 
requirements of ITU-T Recommendation 1.130 [32] at stage 2. 

The present document addresses the security architecture required to fulfil the NGN Rl security requirements defined in 
[ 1 ] and includes the definition of security architectures to provide protection for each of the NGN functional 
architecture ([3]) and its subsystems ([6], [4], [27], [26] and [5]). Where appropriate the present document endorses 
security mechanisms defined in other specifications. 

This document addresses the security issues of the NGN core network and the NGN access network(s) up to and 
including the NGN Network Termination (NGN NT) in the residential customer domain. The NGN NT denotes a 
logical demarcation point between the residential customer domain and the NGN core and access networks and covers 
the corresponding interfaces. 
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Definitions and abbreviations 



3.1 Definitions 

For the purposes of the present document, the following terms and definitions apply: 

Authentication Service (AUTH): See ITU-T Recommendation X.811 [34]. 

Authorization Service (AUTHOR): See ITU-T Recommendation X.812 [35]. 

Confidentiality Service (CONF): See ITU-T Recommendation X.814 [36]. 

data: any information conveyed in communication packets as well as any other information such as topology 
information 

Integrity Service (INT): See ITU-T Recommendation X.815 [37]. 

Key Management Service (KM): See ISO/IEC 11770-1 [31]. 

NGN Network Termination (NGN NT): reference point which denotes a logical demarcation point between the 
residential customer domain and the NGN core via access networks. It covers the corresponding interfaces 

Policy Enforcement Function (PEE): security function that enforces policy rules 

NOTE: The PEF encompasses functions for filtering and topology hiding such as typically found in firewalls 
and/or session border controllers. 

security domain: set of elements made of security policy, security authority and set of security relevant activities in 
which the set of elements are subject to the security policy for the specified activities, and the security policy is 
administered by the security authority for the security domain 

NOTE: The activities of a security domain involve one or more elements from that security domain and, possibly, 
elements of other security domains 

3.2 Abbreviations 

For the purposes of the present document, the following abbreviations apply: 

3G 3'''^ Generation 

3GPP 3'^'^ Generation Partnership Project 

AAA Authentication, Authorization, Accounting 

AF Application Functions 

AGCF Access Gateway Control Function 

AGW Access GateWay 

AKA Authentication and Key Agreement 

AMF Access Management Function 

AN Access Network 

AN Access Node 

AP Access Point 

AP Authentication Proxy 

A-RACF Access-Resource Admission Control Function 

ARE Access Relay Function 

AS Application Server 

ASP Application Service Provider 

AuC Authentication Center 

AUTH AUTHentication Service 

AUTHOR AUTHORization Service 

BGCF Breakout Gateway Control Function 

BSE Bootstrapping Server Functionality 

CLE Connectivity session and repository Location Function 

CONF CONFidentiality service 
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CPE Customer Premises Equipment 

CSCF Call Session Control Function 

DoS Denial-of-Service 

ESP Encapsulating Security Protocol 

FE Functional Entity 

GAA Generic Authentication Architecture 

GBA Generic Bootstrapping Architecture 

GE Generic Entities 

GRE Generic Routing Encapsulation 

HLR Home Location Register 

HSS Home Subscriber Server 

HTTP HyperText Transport Protocol 

IBCF Interconnection Border Control Function 

I-BGF Interconnection Border Gateway Function 

I-CSCF Interrogating Call Session Control Function 

ID IDentity 

IETF Internet Engineering Task Force 

IF InterFace 

IKE Internet Key Exchange 

IMPI IMS Private User ID 

IMPU IMS Public User ID 

IMS IP Multimedia Subsystem 

INT INTegrity service 

IP Internet Protocol 

IPsec Internet Protocol Security 

IRG IMS Residential Gateway 

ISIM IMS Subscriber Identity Module 

lUA ISDN Q.92 1 -User Adaptation 

KM Key Management service 

MGC Media Gateway Controller 

MGCF Media Gateway Control Function 

MRFC Multimedia Resource Function Controller 

MRFP Multimedia Resource Function Processor 

n.a. not applicable 

NACF Network Access Configuration Function 

NAF Network Application Function 

NASS Network Access Subsystem 

NAT Network Address Translation 

NAPT Network Address and Port Translation 

NDS Network Domain Security 

NGN NT NGN Network Termination 

NGN Next Generation Network 

P-CSCF Proxy Call Session Control Function 

PDBF Profile DataBase Function 

PEF Policy Enforcement Function 

PS Packet Switched 

Rl NGN Release 1 

RACS Resource Admission Control Subsystem 

RAND RANDom 

RGW Residential Gate Way 

SA Security Association 

SCS OSA Service Capabihty Server 

S-CSCF Serving Call Session Control Function 

SEGF SEcurity Gateway Function 

SGF Signalling Gateway Function 

SIP Session Initiation Protocol 

SLF Subscription Locator Function 

SPD Security Policy Database 

SPDF Service Policy Decision Function 

TE Terminal Equipment 

THF Topology Hiding Function 

THIG Topology Hiding Interconnection Gateway 
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TISPAN Telecommunication and Internet converged Services and Protocols for Advanced Networking 

TLS Transport Layer Security 

T-MGF Trunking Media Gateway Function 

TS Technical Specification 

UA User Agent 

UAAF User Access Authorization Function 

UE User Equipment 

UICC Universal Integrated Circuit Card 

UMTS Universal Mobile Telecommunication System 

UPSF User Profile Server Function 

USIM UMTS Subscriber Identity Module 

VGW Voice over IP Gate Way 

WLAN Wireless Local Area Network 

XCAP XML Configuration Access Protocol 

XML extensible Markup Language 



4 



NGN Security 



This clause provides an overview of the NGN security document. The entire document can be seen as a documented 
output of a security process that loops through several stages; see figure 1, where arrows indicate logical steps and 
dependencies. 

The present document assumes existence of a well-defined NGN architecture ([3]) that includes the IMS architecture 
(TS 123 002 - see bibliography), the network attachment subsystem (NASS) architecture ([6], the resource admission 
subsystem (RACS) architecture ([5]), and the PSTN/ISDN emulation (PES) architecture ([4]). Likewise, the present 
document assumes the corresponding IMS security architecture ([42]). IMS architecture and IMS security architecture 
are shown as dashed boxes; those prerequisites are not specified further in the present document. 

The description of the NGN release 1 security architecture has been divided in a number of smaller blocks describing 
the security interfaces, the security functions and security protocols, security building blocks and security components. 



NGN architecture (NASS, RACS, PES, IMS) 



IMS Security Architecture 



NGN Release I Security 
Requirements (TS 187001) 



NGN Release I Threat & Risk Analysis 
(TR 187 002) 



NGN Release 1 Security Architecture with security interfaces for NASS, RACS, PES, IMS (TS 187 003) 



Security Domains 



Security Services 



Security Functions 



Countermeasures 



Security Components/ Security Building Blocks 



NGN Release 2 Security Architecture with security interfaces (ffs) 



Figure 1 : Overview of NGN security documents 

Security architecture(s) for further and future NGN releases beyond NGN Release 1 will be specified by separate 
documents. 
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4.1 NGN security architecture 

The NGN Rl security architecture basically consists of the following major parts: 

• NGN security domains (see clause 4.3). 

• Security services (see clause 5): 

authentication; 
authorization; 
policy enforcement; 
key management; 
confidentiality; and 
integrity. 

• Security protocols including those contained in: 

IMS Access Security [8] (in case there are no NATs on the Gm interface); 
SIP HTTP-digest [29] (for NGN legacy UE); 
XCAP [7], presence security [11]. 

• Application specific key management. 

• SEGFs to secure signalling and control communication among network entities/FEs. Security gateways 
(SEGs) for IMS network domain security - as defined by [9] - are considered primarily functional components. 
The present document endorses SEGs and calls them Security Gateway Function (SEGF). 

• IMS Residential Gateway to secure access of legacy UEs (see clause 6). 

• NGN-specific security mechanisms at various protocols/logical layers such as: 

NASS authentication based on explicit line authentication; 

NASS authentication based on implicit physical line authentication; and 

NASS-IMS bundled authentication. 

• NGN subsystem specific security measures (e.g. for PES). 

Figure 2 provides a high level overview of the security FEs within the NGN security architecture. Three logical security 
planes with respective FEs are distinguished: 

• NASS security plane; 

• IMS security plane; 

• GAA/GBA key management plane. 



£75/ 



13 



ETSI TS 187 003 V1.1.1 (2006-03) 

















(GBA Bootstrappinq, opt) 








ISIM 
GBA-U mode 












^__--- 


\ 


Ut Secure session 




^ — — -""^ 


\ 


^..--—-'''''diameter 


BSF 


\ 




■ ~ ^ \ 








~~~----,_ \ 






NAF/AS 


~ ~ - , ^ 


--.,, 


\ 


\ 








IMS AKA 

Security Association 

setup 








■■' 






ISIM 
AKA mode 
























P-CSCF 








S-CSCF 


UPSF 








(e.g. IEEE 802.1 x/PAN A) 


















MASS 
credentials 




























AIVIF 




V-UAAF 


H-UAAF 


PDBF 



Figure 2: Usage of security FEs in the NGN security architecture 

The NASS security plane encompasses the security operations during network attachment for gaining access to the 
NGN access network. The visited UAAF (V-UAAF) in a visited access network relays authentication message to/from 
the home NGN network; the V-UAAF (if present) may be a proxy while the home UAAF (H-UAAF) shall process the 
authentication message and decide authorization. The H-UAAF takes into account user profile information that is stored 
in the PDBF. The PDBF shall hold the profiles of the NASS user. In NGN, an IMS subscriber may register over an IP 
access session established by a NASS subscriber, which may not be the same as the IMS subscriber. Hence, in such 
cases, there is no relation at all between the profile/credentials used at the NASS level and at the IMS level. However, 
the PDBF may be co-located with the UPSF. 

NOTE: The dashed lines between H-UAAF and PDBF and between the NAS/AS and the UPSF indicate 
interfaces which are not defined and standardized in the present document. Specification of such 
interfaces is left as further study. Nevertheless, such an UAAF-PDBF interface is generally required for 
carrying out authentication at NASS level. 

The IMS security plane encompasses the P-CSCF, S-CSCF, I-CSCF (not shown in figure 2) and the UPSF. P-CSCF, 
S-CSCF and I-CSCF shall be involved in the IMS security procedures for authenticating UE and core network, deciding 
authorization, as well as for supplying fresh key material as specified in [8]. The UPSF shall hold the user profiles used 
at the IMS level. 

The GBA/GAA security plane (optional) encompasses the NAF and BSF FEs for application layer security. 

This clause describes the NGN security architecture for Release 1. 



4.2 Security domains 



A security domain (see [30] and [33]) is a set of elements under a given security policy administered by a single 
security authority for some specific security relevant activities. The activities of a security domain involve one or more 
elements from that domain, however at least one of the elements must be in that domain. 

In general, a security domain is required to: 

• protect the integrity, and optionally the confidentiality, of its functional elements and activities; 

• ensure the availability of, and account for the use of, the elements and activities under its protection. 
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The following principal security domains are identified in the general case where the visited network provider hosts 
some IMS services and the core IMS provider in the home network domain further provides IMS services: 

• Customer's domain that includes UE (owned by customer or by operator). 

• Access network security domain with FEs hosted by the access network provider. 

• Visited NGN network security domain with FEs hosted by a visited network provider where the visited 
network may provide access to some application services (AF). The visited network provider may host some 
applications and may own an own database of subscribers. Alternatively, or additionally, the visited network 



provider may outsource some application services to the home network provider or even to a 3 
provider. 



application 



• Home NGN network security domain with FEs hosted by the home network provider where the home network 
may provide some application services (AF). The home network provider hosts some applications and owns a 
database of subscribers. 

• 3rd party application network security domain with FEs hosted by the ASP where the ASP provides some 
application services (AF). The ASP may be a separate service provider different from the visited or the home 
network provider. The ASP may need to deploy authorization information offered by the visited or home 
network provider. 

Figure 3 shows the partitioning of the NGN network into security domains. 

NOTE: The box labelled "APPL" denotes hosted applications; applications are optional. 












APPL 




3rd 


party ASP Network 
Security Domain 



Access Network Security 
Domain 



Visited NGN Network 
Security Domain 



Home NGN Network 
Security Domain 



Figure 3: NGN security domains 
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4.3 NASS and RACS security architecture 

Figure 4 shows a high-level view of the NASS and RACS subsystems as mapped to the five NGN security domains. 



3"^ party ASP Network Security Domain 



Access Network Security Domain 



Visited NGN Network Security Domain 



3'^^ party ASP Network 
Security Domain 












APPL 






/ 





NASS 



RACS 



Home NGN Network 
Security Domain 



Figure 4: NASS and RACS NGN architecture withi security domains 

SEGFs security shall protect the interdomain interfaces between the NGN network security domains. 

Figure 4 shows the most general case. NASS and RACS functional entities are mapped to the networking domains such 
as access transport network, visited NGN network and home NGN network. Those networking domains equally 
represent security domains in the sense of [9] assuming that each networking domain is being operated by a distinct 
operator. SEcurity Gateway Functions (SEGFs) within each security domain shall protect the exposed interfaces 
in-between security domains and ensure that a minimal security poUcy among security domains is enforced. 

SEGFs may also optionally protect the (less exposed, internal) interfaces within a security domain; this is left to the 
discretion of the network operator. The general security architecture case for NASS and RACS subsystems can be 
collapsed iteratively into fewer (security) domains (not shown): e.g. home network and visited network within one 
security domain, or access, visited, home network and ASP network all in one security domain. If 3'''^ party ASP 
network security domain and home network security domain coincide, then the home network actually hosts the 
application. The same holds true for the visited network security and the 3'^'^ party ASP network security domain. 

It is noted that not all interfaces might occur: 

• In NASS scenario 1, the interface e2 with the branches V-CLF-to-H_CLF, V-CLF-to-AF and V-PDBF do not 
occur. 

• In NASS scenario 2, the interface e2 with the branch V-CLF-to-AF and V-PDBF do not occur. 

• In NASS scenario 3, the interfaces e5 and e2 with the branches V-UAAF-to-H-UAAF and V-CLF-to-H-CLF 
do not occur. 

• In NASS scenario 4, the interfaces e5 and e2 with the branches V-UAAF-to-H-UAAF and V-CLF-to-AF do 
not occur. 

It is further noted, that several SEGFs shown as separate functional entities may be co-located; such as for example, the 
SEGFs around Rq and Di interfaces. 

It is noted that there might be further application-specific security protocols (not shown) on top of the Za interfaces. 
Such security protocols (if any) remain for further study. 
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NOTE: On the SEG CA in ASP domains it is observed that those CAs are not peering CAs as among the 

home/visited and access provider. It remains for further study how such SEG CAs could be deployed in 
the context of NGN. 



FEl and FE2 are located in two 
distinct security domains. All 
signaling traffic across interface If 
exchanged between FEl and FE2 
shall be routed through security 
gateway functions (SEGF). 
Za interface (IKE+ESP tunnel) is 
mandatory to implement; Zb 
(IKE+ESP tunnel) is optional to 
implement; see TS 133 210 [10] 
clause 5.6.2. 
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Figures: Legend 
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Figure 6: NGN NASS and RACS security architecture with FEs and security gateway functional 
components around inter-domain interfaces in access, visited, home and other operator's networlcs 

4.3.1 NASS-IMS Bundled Security 

Please refer to clause 4.4. 1 . 
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4.4 IMS security architecture 



The IMS security architecture for both 3G environments and for NGN environments is defined in [8]. 




Figure 7: IMS Security architecture in an NGN environment [8] 

Figure 7 depicts the IMS security architecture in an NGN environment as defined in [8], where the 3GPP specific 
transport domain is replaced by the Generic IP transport domain. The following observations support figure 7. 

• The IMS is independent of the transport network. 

• Generic Entities (GE) equivalent to the 3GPP transport entities will be present in the Generic IP transport 
domain. 

• In NGN the AuC functionality is performed by UPSF. 

• The Security Associations (SA) (referring to the corresponding arrows in figure 7) are retained. 

SA-1, SA-3, SA-4 and SA-5 are endorsed as described in [8]. 

SA-2 is endorsed with the extension to ensure transport across NAT/Firewall boundaries. 

There exist other interfaces and reference points in IMS, which have not been addressed above. Those interfaces and 
reference points reside within the IMS, either within the same security domain or between different security domains 
(see figure 8). The protection of all such interfaces and reference points (which may include subsystems like 
NASS/RACS) apart from the Gm reference point are protected as specified in [9]. 

The present document endorses the interfaces (1) to (5) of [8]. 

Figure 8 details figure 7 by showing the IMS functional entities in the NGN that runs over a generic IP transport. 
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Figure 8: Generic IP Transport underneath IIUIS ([8]) 

In the following, IMS components are segregated into the different security domains. Figure 9 shows the IMS 
components in five different domains. The interconnection between the different IMS components is not shown in the 
figure and it should be in accordance with [27]. The segregation is explained below. 

1) Customer's domain includes UE and optionally some Residential Gateways (which may be owned by the 
user/operator). The Residential Gateway shall have ISIM, which has the credentials for IMS authentication. 

2) Access network domain is hosted by the access network provider. The access network provider may or may 
not be the same as the NGN provider. 

3) Visited network domain is hosted by a visited network provider. The visited network provider may offer 
multimedia services and may have his own subscribers. Alternatively, the visited network provider may have 
agreement with some 3'^'^ party Application Service Provider (ASP) to offer services. The visited network 
domain may encompass IMS functional entities. 

4) Home network domain is hosted by the home network provider. The home network provider offers 
multimedia services. Alternatively, the visited network provider may have agreement with some 3'^'^ party 
Application Service Provider (ASP) to offer services. The home network domain encompasses the IMS 
network. 

5) 3'"'' party application service provider domain is hosted by some ASP different from the operator. The ASP 
may need to deploy its own AAA infrastructure to interpret the information offered by the visited or home 
network provider. It should have the IMS functional entities. 

Figure 9 shows the partitioning of the NGN network with IMS components (pink boxes) into security domains (boxes 
with curved edge). The figure also shows the two different authentications the clients usually go through for NGN 
access, in the scope of NGN Release 1 security architecture. 



1) 



2) 



The connection marked 
Access Network. 



Access Authentication" is the authentication between the UE and NASS in the 



The connection marked IMS Authentication" is the authentication between the UE and the S-CSCF in the IMS 
network. After the successful authentication, a security association is created between the UE and the P-CSCF. 
3GPP R5/R6 has recommended IPsec in transport mode for this. The 3GPP R5/R6 solution lacks NAT 
traversal capability and hence a solution that is capable of NAT traversal is to be used. 

In the figure 9, two distinct interfaces are depicted: 

• The connections between the different IMS components (also NGN components) within the same IMS 

network (NGN network) are the "Zb" interfaces. These interfaces may or may not be protected depending on 
operator policies. 



£75/ 



20 



ETSI TS 187 003 V1.1.1 (2006-03) 



• The connection between the different Operators, denoted by "Za" in the figure, should be protected (IKE, ESP 
tunnel). The SEGFs [9] within each security domain protect the exposed interfaces between operators and 
ensure that a security policy among security domains is enforced. SEGFs may also optionally protect the (less 
exposed, internal) interfaces within a security domain; this is left to the discretion of the network operator. The 
outbound IMS/NGN traffic from an operator cannot by-pass the SEGF. SEGFs are used to protect the traffic 
between two operators. That means traffic from access network IMS entities to IMS entities in the home 
network of a different operator shall go through SEGF. 

The UE may either have ISIM in it (in which case, it can directly authenticate to the S-CSCF) or the ISIM credentials 
may be in the IMS residential gateway (IRG) (wherein, the service authentication has to go through the IRG). The ISIM 
may also be in both the devices. 

The Service Providers (ASP) may or may not have the same CA as the visited/home network. This depends on the 
operator policies. 



/Visited Network/'^ 
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S-CSCF 



UPSF 



IVIGCF 



BGCF 



SLF 



IIVIS-AS 



IMS Network 



Charging 



PSTN 




ASP 



IMS Authentication 
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NOTE: Figure 9 does not show any optional SEGF within a security domain for securing the communication 
among IIVIS FEs inside the same security domain. 

Figure 9: IMS security domains 

4.4.1 NASS-IMS Bundled Security 

The NASS Bundled Authentication (NBA) works by extending the successful authentication in the NASS layer to the 
service layer. 

During the network attachment, the NASS authenticates the UE and allocates an IP address. It stores the layer-2 and 
layer-3 identities in the NASS profile. When UE registers with the P-CSCF, the P-CSCF queries the NASS (actually the 
CLE functional entity), to obtain its location information. The P-CSCF embeds the location information into the SIP 
message and forwards it towards the S-CSCF for verification. The S-CSCF verifies this location information with the 
location information obtained from the UPSF. On successful verification, the user is authenticated at the IMS layer. 
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At the architectural level, two interfaces are affected: 

1) the "e2" interface over which the location info from the NASS is communicated. 

2) the "Cx" interface over which the user profile stored in UPSF is transmitted. 
This is illustrated in figure 10. See also annex D for a visualization of the network flows. 
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Figure 10: Formal mapping of NASS Bundled Authentication 



4.5 PES Security Architecture 
4.5.1 Security for H.248 within PES 

Figure 1 1 depicts the security architecture for using H.248. 1 for PSTN/ISDN service over IP according to [20]. Access 
Gateway (AGW), Residential Gateway (RGW), the control subsystem (AGCF with MGC) and the control protocols are 
considered to belong entirely to a single operator's security domain as indicated by the dashed, red line. 

The specified H.248 security options should not be used, as these interfaces are considered to be within a security 
domain. [20] clause 5.1.3 specifies that no security measures, either IPsec or TLS, are used on the lUA interfaces and 
no specific countermeasures are applied to the GRE interface carrying packet data. 

NOTE: In any other case when the H.248, lUA and GRE interfaces do not fall within a single operator's security 
domain, a different risk may apply and appropriate countermeasures may be needed. A security 
architecture for such cases is left as for further study. 
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Figure 1 1 : Reference architecture for profile of the Gateway Control Protocol (H.248. 1), for controlling 

access and residential gateways connecting analog lines and ISDN primary and 

basic accesses, in order to emulate PSTN/ISDN services over IP [20] 

4.5.2 IMS-based PES Security 

[41] defines the functional architecture for the IMS -based PSTN/ISDN emulation subsystem. The MGCF maps the 
encapsulated ISUP information within SIP messages sent/received to/from the BGCF (Mj interface) and to/from the 
I/S-CSCF (Mg interface) to the ISDN/PSTN network. The MGCF implements the role of a PES Interworking 
Application while the IBCF implements the role of a PES Interconnection application, see [40]. 

Procedures for filtering ISUP information off from SIP messages are specified in [40] clauses 5.3.3.5.2.4, 5.3.5.4.2.4 
and 5.3.6.2. 

In the context of PES, TR 183 032 (see bibliography) clause 6.2 and TR 183 014 (see bibliography) provide 
supplementary information on the feasibility of securing encapsulated ISUP information within SIP. 



4.6 Application security architecture 



The AS architecture enables the user to manage information related to his services, such as creation and assignment of 
Public Service Identities, management of authorization policies that are used e.g. by Presence service, conference policy 
management, etc. 

The XCAP architecture and security architecture is endorsed by [7]. This defines the usage of a set of security protocols 
for protection of XCAP traffic on the Ut interface between UE and AS. The two optional method endorsed are HTTP 
digest over TLS and GAA [12]. An authentication proxy may be used optionally for user authentication, as defined in 
[7] and [12], see figure 12. 



UE 




Authentication 
Proxy 




AS 


Ut 


Ut 



Figure 12: Authentication proxy in the Ut interface path 
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5 Mapping of Security Requirements to Security 

Services and NGN FEs 

5.1 Security services in NGN R1 security architecture 

This clause defines the mapping of security services within the NGN Rl security architecture through security 
functions. Clause 4.2.3 provides a mapping of security services to NGN FEs. 

The following security services are identified for NGN: 

• Authentication. 

• Authorization. 

• Confidentiality. 

• Integrity. 

Tables 1 to 4 show the security services along with the NGN interfaces between the major NGN subsystems (UE/CNG 
responsible VGW, NASS, RACS, IMS, PES and AS). The tables only show the interfaces with mandatory security; 
interfaces with optional security measures are not shown. 

NOTE: Since the table is symmetric, the lower left triangular (shaded grey) is supposed to convey the same 
entries as shown in the upper right triangular. 

Table 1 : NGN interfaces with required Authentication security services (AUTIH) 





UE/CNG, 
VGW 


NASS 


RACS 


IMS 


PES 


AS 


UE/CNG, VGW 


n.a. 


e1 


n.a. 


Gm 


Gm 


Ua, Ub, Ut, Zn 


NASS 




a3, e5 


e4 


n.a 


n.a. 


e2 


RACS 






Rq 


n.a. 


n.a. 


Gq' 


IMS 








Cx, Dx 


n.a. 


Sh,Zh 


PES 








■ 


n.a. 


n.a. 


AS 








! ^" 


_ 


n.a. 



Table 2: NGN interfaces with required Confidentiality Security services (CONF) 





UE/CNG, 
VGW 


NASS 


RACS 


IMS 


PES 


AS 


UE/CNG, VGW 


n.a. 


e1 


n.a. 


Gm 


Gm 


Ua, Ub, Ut, Zn 


NASS 




a3, e5 


e4 


n.a. 


n.a. 


e2 


RACS 


L 




Rq 


n.a 


n.a. 


Gq' 


IMS 


P 






Cx, Dx, Ic 


n.a. 


Sh, Zh 


PES 










n.a. 


n.a. 


AS 












n.a. 



Table 3: NGN interfaces with required Integrity security services (INT) 





UE/CNG, 
VGW 


NASS 


RACS 


IMS 


PES 


AS 


UE/CNG, VGW 


n.a. 


e1 


n.a. 


Gm 


Gm 


Ua, Ub, Ut, Zn 


NASS 
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a3, e5, Za 


e4 


n.a 


n.a. 
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Rq 


n.a 


n.a. 
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Cx, Dx 


n.a. 


Sh, Zh 


PES 










n.a. 


n.a. 


AS 


L 








^ 


n.a. 
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Table 4: NGN interfaces with required Key IVIanagement security services (KIV!) 





UE/CNG, 
VGW 


NASS 


RACS 


IMS 


PES 


AS 


UE/CNG, VGW 


n.a. 


e1 


n.a. 


Gm 


Gm 


Ua, Ub, Ut, Zn 


MASS 




a3, e5, Za 


e4 


n.a 


n.a. 


e2 


RACS 






Rq 


n.a 


n.a. 


Gq' 


IMS 








Cx, Dx 


n.a. 


Sh,Zh 


PES 


L 






J n.a. 


n.a. 


AS 


L 






_^^^^^^^^^l n.a. 



5.2 Security Services in NGN FEs 

Table 5 identifies the security services with the security mechanism(s) and countermeasures for each NGN FE. 

NOTE: Security functions of security services may actually be specified in documents that are referenced 
indirectly only. 

Table 5: Security services and countermeasures provided by NGN FEs 



NGNFE 


Security Services 


Countermeasure and security mechanism in NGN R1 


Access Point 
(AP) 


AUTH 


Authentication for AP are as specified by [22]. 


AUTHOR 


Autliorization functions for AP are as specified by [22]. 


CONF 


Confidentiality functions for AP are as specified by [22]. 


INT 


Integrity functions for AP are as specified by [22]. 


KM 


Key management functions for AP are as specified by [22]. 


PEF 


n.a. 


AGCF, AGW, 
RGW 


AUTH 


Assumed to be in the trusted domain, see [20]. 


AUTHORF 


Assumed to be in the trusted domain, see [20]. 


CONF 


Assumed to be in the trusted domain, see [20]. 


INT 


Assumed to be in the trusted domain, see [20]. 


KM 


Assumed to be in the trusted domain, see [20]. 


PEF 


Assumed to be in the trusted domain, see [20]. 


A-RACF 


AUTH 


Authentication functions for securing the e4 interface for A-RACF are as 
specified by [24]. 

Authentication functions for securing the Rq interface for A-RACF are as 
specified by [43]. 


AUTHOR 


Authorizations functions for securing the e4 interface for A-RACF are as 
specified by [24]. 

Authorizations functions for securing the Rq interface for A-RACF are as 
specified by [43]. 


CONF 


Confidentiality functions for securing the e4 interface for A-RACF are as 
specified by [24]. 

Confidentiality functions for securing the Rq interface for A-RACF are as 
specified by [43]. 


INT 


Integrity functions for securing the e4 interface for A-RACF are as specified 
by [24]. 

Integrity functions for securing the Rq interface for A-RACF are as specified 
by [431. 


KM 


Key management functions for securing the e4 interface for A-RACF are as 
specified by [24]. 

Key management functions for securing the Rq interface for A-RACF are as 
specified by [43]. 


PEF 


Policy enforcement functions for securing the e4 interface for A-RACF are as 
specified by [24]. 

Policy enforcement functions for securing the Rq interface for A-RACF are 
as specified by [43]. 
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NGNFE 


Security Services 


Countermeasure and security mechanism in NGN R1 


AS 


AUTH 


Autlientication functions for AS are as specified by [1 1] and by [7]. 
Authentication functions for securing the DIAMETER protocol for AS are as 
specified by [19] and by [9]. 


AUTHOR 


Authorization functions for AS are as specified by [1 1] and by [7]. 
Authorization functions for securing the DIAMETER protocol for AS are as 
specified by [19] and by [9]. 


CONF 


Confidentiality functions for AS are as specified by [11] and by [7]. 
Confidentiality functions for securing the DIAMETER protocol for AS are as 
specified by [19] and by [9]. 


INT 


Integrity functions for AS are as specified by [1 1] and by [7]. 
Integrity functions for securing the DIAMETER protocol for AS are as 
specified by [19] and by [9]. 


KM 


Key management functions for AS are as specified by [1 1] and by [7]. 

Key management functions for securing the DIAMETER protocol for AS are 

as specified by [19] and by [9]. 


PEF 


Policy enforcement functions for filtering encapsulated ISUP within SIP in 
the AS are specified by [40] clauses 5.3.3.5.2.4 and 5.3.5.4.2.4. 


Authentication 
Proxy (AP) 


AUTH 


Authentication functions for AP are as specified by [7] and [12]. 


AUTHOR 


Authorization functions for AP are specified by [7] and [1 2]. 


CONF 


Confidentiality functions for AP are specified by [7] and [12]. 


INT 


Integrity functions for AP are specified by [7] and [12]. 


KM 


Key management functions for AP are as specified by [7] and [12]. 


PEF 


Policy enforcement functions for AP are as specified by [7] and [12]. 


BGCF 


AUTH 


n.a. 


AUTHOR 


n.a. 


CONF 


n.a. 


INT 


n.a. 


KM 


n.a. 


PEF 


n.a. 


BSF 


AUTH 


Authentication functions for BSF are as specified by [13]. 


AUTHOR 


Authorization functions for BSF are as specified by [13]. 


CONF 


Confidentiality functions for BSF are as specified by [13]. 


INT 


Integrity functions for BSF are as specified by [13]. 


KM 


Key management functions for BSF are as specified by [13]. 


PEF 


n.a. 


CLF 


AUTH 


Authentication functions for securing the e2 interface of the CLF are as 
specified by [23]. 


AUTHOR 


Authorizations functions for securing the e2 interface of the CLF are as 
specified by [23]. 


CONF 


Confidentiality functions for securing the e2 interface of the CLF are as 
specified by [23]. 


INT 


Integrity functions for securing the e2 interface of the CLF are as specified 
by [23]. 


KM 


Key management functions for securing the e2 interface of the CLF are as 
specified by [23]. 


PEF 


Policy enforcement functions for securing the e2 interface of the CLF are as 
specified by [23]. 


IBCF 


AUTH 


n.a 


AUTHOR 


Authorization functions for IBCF are as specified by [28]. 


CONF 


Confidentiality functions for IBCF are as specified by [28]. 


INT 


n.a. 


KM 


n.a. 


PEF 


Policy enforcement functions for IBCF are as specified by [28]. 

Policy enforcement functions for filtering encapsulated ISUP within SIP in 

the IBCF are specified by [40], clause 5.3.6.2. 


IRG 


AUTH 


IMS-AKA authentication functions for IRG shall are as specified in [8]; 
Authentication functions for IPsec packet authentication in the IRG are as 
specified in [8]. 

Optional authentication functions for SIP HTTP-digest in the IRG are as 
defined in [29]. 


AUTHOR 


Authorization functions in the IRG are as specified in [8]. 


CONF 


Confidentiality functions in the IRG protect IMS-AKA key distribution against 

loss of confidentiality as specified in [8]. 

Confidentiality functions in the IRG encrypt IPsec packets as specified in [8]. 
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NGNFE 


Security Services 


Countermeasure and security mechanism in NGN R1 




INT 


Integrity functions in the IRQ protect IMS-AKA key distribution against loss of 
integrity as specified in [8]. 

Integrity functions in tlie IRQ protect IPsec pacl<ets against loss of integrity 
as specified in [8]. 


KM 


Key management functions in the IRQ provide IMS-AKA as specified in [8]. 


PEF 


n.a. 


MGCF 


AUTH 


n.a. 


AUTHOR 


n.a. 


CONF 


n.a. 


INT 


n.a. 


KM 


n.a. 


PEF 


Policy enforcement functions for filtering encapsulated ISUP within SIP in 






the MGCF are specified by [40]. 


NAF 


AUTH 


Authentication functions in NAF are as specified by [12]. 


AUTHOR 


Authorization functions in NAF are specified by [12]. 


CONF 


Confidentiality functions in NAF are specified by [12]. 


INT 


Integrity functions in NAF are specified by [12]. 


KM 


Key management functions in NAF are as specified by [12]. 


PEF 


n.a. 


PDBF 


AUTH 


Authentication functions in the PDBF retrieve authentication data (e.g. user 
identity, list of supported authentication methods, authentication keys etc.) 
as outlined in [6]. 


AUTHOR 


Authorization functions in the PDBF access PDBF to retrieve authorization 






data (e.g. user network profile) as outlined in [6]. 


CONF 


n.a. 


INT 


n.a. 


KM 


n.a. 


PEF 


n.a. 


P-CSCF 


AUTH 


Authentication functions in the P-CSCF provide IMS-AKA as specified in [8]. 

Authentication functions in the P-CSCF provide IPsec packet authentication 

as specified in [8]. 

Optional authentication functions in the P-CSCF provide NASS-IMS bundled 

authentication as specified in [26] and [7]. 

Optional authentication functions in the P-CSCF support SIP HTTP-digest as 

defined in [29]. 

Authentication functions in the P-CSCF secure the e2 interface as specified 

by [23]. 

Authentication functions in the P-CSCF secure the e4 interface as specified 

by [24]. 


AUTHOR 


Authorization functions in the P-CSCF provide authorization functions as 






specified in [8]. 






Authorization functions in the P-CSCF provide authorizations functions for 






securing the e2 interface as specified by [23]. 






Authorization functions in the P-CSCF provide authorizations functions for 






securing the e4 interface as specified by [24]. 






Optional authorization functions in the P-CSCF for NASS-IMS bundled 






authentication feature as specified in [26] and [7]. 






Optional authorization functions in the P-CSCF support SIP HTTP-digest as 






defined in [29]. 


CONF 


Confidentiality functions in the P-CSCF provide IMS-AKA key distribution 






against loss of confidentiality specified in [8]. 






Confidentiality functions in the P-CSCF provide IPsec packet encryption as 






specified in [8]. 






Confidentiality functions in the P-CSCF secure the e2 interface as specified 






by [23]. 






Confidentiality functions in the P-CSCF secure the e4 interface as specified 






by [24]. 


INT 


Integrity functions in the P-CSCF protect IMS-AKA key distribution against 






loss of integrity as specified in [8]. 






Integrity functions in the P-CSCF protect IPsec packets against loss of 






integrity as specified in [8]. 






Integrity functions in the P-CSCF secure the e2 interface as specified by 

[23]. 

Integrity functions in the P-CSCF secure the e4 interface as specified by 










[24]. 
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KM 


Key management functions in the P-CSCF provide IMS-AKA as specified in 

[8]. 

Key management functions in the P-CSCF shall secure the e2 interface as 

specified by [23]. 

Key management functions in the P-CSCF secure the e4 interface as 

specified by [24]. 


PEF 


Policy enforcement functions in the P-CSCF secure the e2 interface as 

specified by [23]. 

Policy enforcement functions in the P-CSCF secure the e4 interface as 

specified by [24]. 

Policy enforcement functions for filtering encapsulated ISUP within SIP in 

the P-CSCF are specified by [40] clause 5.3.3.5.2.4. 


S-CSCF 


AUTH 


Authentication functions for securing DIAMETER over SCTP using IPsec in 
the S-CSCF are as specified by [7] and by [9]. 


AUTHOR 


Authorization functions for securing DIAMETER over SCTP using IPsec in 
the S-CSCF are as specified by [7] and by [9]. 


CONF 


Confidentiality functions for securing DIAMETER over SCTP using IPsec in 
the S-CSCF are as specified by [7] and by [9]. 


INT 


Integrity functions for securing DIAMETER over SCTP using IPsec in the 
S-CSCF are as specified by [7] and by [9]. 


KM 


Key management functions for securing DIAMETER over SCTP using IPsec 
in the S-CSCF are as specified by [7]] and by [9]. 


PEF 


n.a. 


SEGF 


AUTH 


Authentication functions in the SEGF provide IKE as specified in [9]. 
Authentication functions in the SEGF provide IPsec packet authentication as 
specified in [9]. 


AUTHOR 


Authorization functions in the SEGF provide IKE/IPsec SPD as specified in 
[9]. 


CONF 


Confidentiality functions in the SEGF provide IPsec packet encryption as 
specified in [10]. 


INT 


Integrity functions in the SEGF provide IPsec packet integrity as specified in 
[10]. 


KM 


Key management functions in the SEGF provide IKE as specified in [10]. 


PEF 


Policy enforcement for AUTH, AUTHOR, CONF, INT and KM in the SEGF 
are as specified in [10]. 


THF, l-CSCF 
(THIG) 


AUTH 


n.a. 


AUTHORF 


n.a. 


CONF 


n.a. 


INTF 


n.a. 


KM 


n.a. 


PEF 


Topology hiding functions in THF, l-CSCF (THIG) are as specified in [29] 
(see TS 124 229 - see bibliography). 


UAAF 


AUTH 


Explicit and/or implicit authentication functions for NASS in the UAAF are as 
specified by [22]; see also [6]. 

The UAAF terminates the AAA protocol (RADIUS or DIAMETER) as a AAA 
server, see [6]. 


AUTHOR 


Authorization functions for NASS (supported by PDBF) in the UAAF are as 
specified by [22]. 


CONF 


n.a. 


INT 


n.a. 


KM 


n.a. 


PEF 


The UAAF supports the Privacy Indicator to indicate whether location 
information can be exported to services and applications; see [6]. 


UPSF 

NOTE: UPSF 
does not directly 
correspond to a 
security 
function, nor 
does UPSF 
provide a 
security service. 


AUTH 


For IMS, the authentication function in the UPSF accesses authentication 
data stored in the UPSF (see also [3], TR 182 005 - see bibliography, see 
also clause A.2). 


AUTHOR 


For IMS, the authorization function in the UPSF accesses authorization data 
stored in the UPSF (see also [3], TR 182 005 - see bibliography, see also 
clause A.2). 


CONF 


For IMS, the confidentiality function in the UPSF accesses keys stored in the 
UPSF (see also [3], TR 182 005 - see bibliography, see also clause A.2). 


INT 


For IMS, the integrity function in the UPSF accesses integrity data stored in 
the UPSF (see also [3], TR 182 005 - see bibliography, see also clause A.2). 


KM 


For IMS, the key management function accesses key management data 
stored in the UPSF (see also [3], TR 182 005 - see bibliography, see also 
clause A.2). 
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PEF 


For IMS, the policy enforcement function in the UPSF accesses policy 
information stored in the UPSF (see also [3], TR 182 005 - see bibliography, 
see also clause A.2). 



5.3 Security Services on NGN Interfaces 

Table 6 identifies the security services (AUTH, INT, CONF, KMF) with the security mechanism(s) and 
countermeasures for each NGN interface. 

NOTE 1 : Interfaces are not listed in this clause where no security functions are identified. 

NOTE 2: Security functions of the security services may actually be specified in documents that are referenced 
indirectly only. 

Table 6: Security services and countermeasures provided by NGN interfaces 



NGN IF 


Security 
Services 


Countermeasure and security mechanism In NGN R1 


a3 

(UAAF - AMF) 


AUTH 


Authentication functions for the aS IF are as specified by [22]. 


CONF 


Confidentiality functions for the a3 IF are as specified by [22]. 


INT 


Integrity functions for the aS IF are as specified by [22]. 


KM 


Key management functions for the aS IF are as specified by [22]. 


a4 

(UAAF - CLF) 


AUTH 


n.a. 


CONF 


n.a. 


INT 


n.a. 


KM 


n.a. 


Cx 

(S-CSCF - 
UPSF) 


AUTH 


Authentication functions for securing DIAMETER over SCTP using IPsec for the 
CX IF are as specified by [7] and by [9]. 


CONF 


Confidentiality functions for securing DIAMETER over SCTP using IPsec for the 
CX IF are as specified by [7] and by [9]. 


INT 


Integrity functions for securing DIAMETER over SCTP using IPsec for the CX IF 
are as specified by [7] and by [9]. 


KM 


Key management functions for securing DIAMETER over SCTP using IKE for 
the CX IF are as specified by [7] and by [9]. 


Dx 

(S-CSCF - 
UPSF-SLF) 


AUTH 


Authentication functions for securing DIAMETER for the DX IF are as specified 
by [7] and by [9]. 


CONF 


Confidentiality functions for securing DIAMETER for the DX IF are as specified 
by [7] and by [9]. 


INT 


Integrity functions for securing DIAMETER for the DX IF are as specified by [7] 
and by [9]. 


KM 


Key management functions for securing DIAMETER for the DX IF are as 
specified by [7] and by [9]. 


e1 
(CNG-AMF) 


AUTH 


Authentication functions for e1 IF are as specified by [22] and by [9]. 


CONF 


Confidentiality functions for e1 IF are as specified by [22]. 


INT 


Integrity functions for e1 IF are as specified by [22]. 


KM 


Key management functions for e1 IF are as specified by [22]. 


e2 

(CLF - AF) 


AUTH 


Authentication functions for securing the e2 interface are as specified by [23]. 


CONF 


Confidentiality functions for securing the e2 interface are as specified by [23]. 


INT 


Integrity functions for securing the e2 interface are as specified by [23]. 


KM 


Key management functions for securing the e2 interface are as specified by [23]. 


e4 

(CLF - A-RACF) 


AUTH 


Authentication functions for securing the e4 interface are as specified by [24]. 


CONF 


Confidentiality functions for securing the e4 interface are as specified by [24]. 


INT 


Integrity functions for securing the e4 interface are as specified by [24]. 


KM 


Key management functions for securing the e4 interface are as specified by [24]. 


e5 

(UAAF - UAAF) 


AUTH 


Authentication functions for the e5 IF are as specified by [22]. 

e5 provides the AAA protocol (RADIUS or DIAMETER) as specified by [6]. 


CONF 


Confidentiality functions for the e5 IF are as specified by [22]. 


INT 


Integrity functions for the e5 IF are as specified by [22]. 


KM 


Key management functions for the e5 IF are as specified by [22]. 
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NGN IF 


Security 
Services 


Countermeasure and security mechanism In NGN R1 


Gm 

(UE/IRG - 
P-CSCF) 
(VGW- 
P-CSCF) 


AUTH 


Authentication functions for the Gm IF provide IMS-AKA as specified in [8]. 

Authentication functions for the Gm IF provide IPsec packet authentication as 

specified in [8]. 

Optional authentication functions for the Gm IF provide SIP HTTP-digest as 

defined in [29]. 

Optional authentication functions for the Gm IF provide NASS-IMS bundled 

authentication as specified in [26] and [7]. 


CONF 


Confidentiality functions for the Gm IF protect IMS-AKA key distribution against 
loss of confidentiality specified in [8]. 

Confidentiality functions for the Gm IF protect IPsec packet encryption as 
specified in [8]. 


INT 


Integrity function for the Gm IF protect IMS-AKA key distribution against loss of 

integrity as specified in [8]. 

Integrity function for the Gm IF protect IPsec packet integrity as specified in [8]. 


KM 


Key management functions for the Gm IF provide IMS-AKA as specified in [8]. 


Gq' 

(AF - SPDF) 


AUTH 


Authentication functions for securing DIAMETER for Gq' are as defined by [38]. 


CONF 


Confidentiality functions for securing DIAMETER for Gq' are as defined by [38]. 


INT 


Integrity functions for securing DIAMETER for Gq' are as defined by [38]. 


KM 


Key management functions for securing DIAMETER for Gq' are as defined by 
[38]. 


la 

(SPDF - BGF) 


AUTH 


la IF does not provide any authentication functions; see [21]. 


CONF 


la IF does not provide any confidentiality functions; see [21]. 


INT 


la IF does not provide any integrity functions; see [21]. 


KM 


la IF does not provide any key management functions; see [21]. 


Ic 
(IBCF-IBCF) 


AUTH 


n.a. 


CONF 


Confidentiality functions for Ic are as specified by [28]. 


INT 


n.a. 


KM 


n.a. 


ISC 
(CSCF - AS) 


AUTH 


n.a. 


CONF 


n.a. 


INT 


n.a. 


KM 


n.a. 


Mg 

(CSCF - MGCF) 


AUTH 


n.a. 


CONF 


n.a. 


INT 


n.a. 


KM 


n.a. 


Mj 

(BGCF - MGCF) 


AUTH 


n.a. 


CONF 


n.a. 


INT 


n.a. 


KM 


n.a. 


Rq 

(SPDF- 

A-RACF) 


AUTH 


Authentication functions for securing the DIAMETER protocol for the Rq IF are 
as specified by [43]. 


CONF 


Confidentiality functions for securing the DIAMETER protocol for the Rq IF are 
as specified by [43]. 


INT 


Integrity functions for securing the DIAMETER protocol for the Rq IF are as 
specified by [43]. 


KM 


Key management functions for securing the DIAMETER protocol for the Rq IF 
are as specified by [43]. 


Sh 

(AS - UPSF) 

(SCS - UPSF) 


AUTH 


Authentication functions for securing the DIAMETER protocol for the Sh IF are 
as specified by [19] and by [9]. 


CONF 


Confidentiality functions for securing the DIAMETER protocol for the Sh IF are 
as specified by [19] and by [9]. 


INT 


Integrity functions for securing the DIAMETER protocol for the Sh IF are as 
specified by [19] and by [9]. 


KM 


Key management functions for securing the DIAMETER protocol for the Sh IF 
are as specified by [19] and by [9]. 


Ua 

(NAF-UE) 


AUTH 


Authentication functions for Ua IF are as specified by [13]. 


CONF 


Confidentiality functions for Ua IF are as specified by [13]. 


INT 


Integrity functions for Ua IF are as specified by [13]. 


KM 


Key management functions for Ua IF are as specified by [13]. 


Ub 
(BSF-UE) 


AUTH 


Authentication functions for Ub IF are as specified by [13]. 


CONF 


Confidentiality functions for Ub IF are as specified by [13]. 


INT 


Integrity functions for Ub IF are as specified by [13]. 


KM 


Key management functions for Ub IF are as specified by [13]. 
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NGN IF 


Security 
Services 


Countermeasure and security mechanism in NGN R1 


Ut 

(UE - (AP) - AS) 


AUTH 


Authentication functions for Ut IE are as specified by [11], [12] and by [7]. 


GONE 


Confidentiality functions for Ut IE are as specified by [11], [12] and by [7]. 


INT 


Integrity functions for Ut IE are as specified by [11], [12] and by [7]. 


KM 


Key management functions for Ut IE are as specified by [12], [11] and by [7]. 


Za 

(SEGF - SEGF) 


AUTH 


Authentication functions for Za IE are as specified in [9]. 


CONE 


Confidentiality functions for Za IE are as specified in [9]. 


INT 


Integrity functions for Za IE are as specified in [9]. 


KM 


Key management functions for Za IE are as specified in [9]. 


Zb 

(SEGF-FE) 


AUTH 


Optional authentication functions for Zb IE areas specified in [9]. 


CONE 


Optional confidentiality functions for Zb IE are as specified in [9]. 


INT 


Optional integrity functions for Zb IE are as specified in [9]. 


KM 


Optional l<ey management functions for Zb IE are as specified in [9]. 


Zh 
(BSF-UPSF) 


AUTH 


Authentication functions for Zh IE are as specified by [13]. 


CONE 


Confidentiality functions for Zh IE are as specified by [13]. 


INT 


Integrity functions for Zh IE are as specified by [13]. 


KM 


Key management functions for Zh IE are as specified by [13]. 


Zn 
(BSF-UE) 


AUTH 


Authentication functions for Zn IE are as specified by [13]. 


CONE 


Confidentiality functions for Zn IE are as specified by [1 3]. 


INT 


Integrity functions for Zn IE are as specified by [13]. 


KM 


Key management functions for Zn IE are as specified by [13]. 



5.4 Mapping of 3GPP security FEs to NGN FEs 

NGN shall re-use 3GPP security entities (AuC, HLR and HSS; see TS 123 002) as follows; see also figure 13 that 
illustrates a mapping of 3GPP FEs to NGN FEs: 

• The PDBF at the NASS level shall conceptually encompass the same functionality that is provided by the 
AuC, see TS 123 002 clause 4.1.1.1.2. Additionally, the PDBF shall contain the NASS level profiles needed 
for the NASS layer authentication. 

NOTE 1 : Conceptually means that the functionality is not the same as AuC operates at IMS level while PDBF 
operates at NASS level. Thus, the functions of the AuC need to be transposed into some conceptually 
equivalent functions at the PDBF. 

• When mapping the 3GPP PS domain architecture to the NASS architecture, the H-UAAF conceptually covers 
the part of the HLR that is used to access the AuC; see figure 13, see TS 123 002 clause 4.1.1.1.1. 

When mapping the 3GPP WLAN architecture to the NASS architecture, the H-UAAF is equivalent to the 
WLAN H-AAA server, while the V-UAAF is equivalent to a WLAN AAA proxy; see figure 14, see 
TS 133 234 clause 4.1.4. 

• The UPSF as a generic FE shall encompass: 

authentication data for the IMS are held in the non-HLR part of the HSS. However, this part of the HSS 
is not explicitly termed AuC. This part is shown as AuC to represent the AuC functionality for the IMS 
(i.e. ISIM-based). This AuC functionahty is inherited by the UPSF. 

some other HSS functionality (different from AuC and HLR). 

NOTE 2: The HSS is defined in TS 123 002 clause 4.1.1.1. 

Generally, NGN FEs shall not encompass any 3GPP functionality that relates to supporting the CS and PS domain. 

Figures 13 and 14 show interfaces: 

• PDBF - UAAF: This interface is not defined in Rl . 

• Components and interfaces within UPSF are not defined in Rl. 

• Internal interfaces within HSS are not defined in 3GPP. 
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NOTE 3: Figures 13 and 14 show relationships and are not meant to imply exact correspondences, appears to be 
correct on a high level. Some details can of course not be mapped precisely. This is because the 
architectural assumptions on the environment of user data in 3GPP and in NGN are somewhat different. 
In particular, the scopes of UAAF and HLR are different. 

NOTE 4: IMS data also contains AuC data related to ISIM. 
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Figure 13: Mapping of HSS (AuC, HLR) to PDBF, UPSF, UAAF (PS domain) 
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Figure 14: IVIapping of HSS (AuC, HLR) to PDBF, UPSF, UAAF (WLAN case) 
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NGN IMS Residential Gateway 



User may gain access to NGN IMS services by using a non-ISIM capable SIP UA via a NGN IMS Residential Gateway 
(IRG). NGN IMS Residential Gateway is an optional functional element within the NGN architecture and serves the 
purpose to securely connect legacy, non-NGN UE equipment to the NGN that does not have the capability of using an 
ISIM/UICC. The IRG holds a SIP B2BUA, which has a full NGN IMS Release 1 UA interface towards the NGN IMS 
network. The interface towards to the local user is not specified by the present document; however, it could be for 
example IETF compatible SIP UA [29], softphone, IP phone, IAD/DECT or some other possibly proprietary phone 
system. The IMS Residential Gateway is placed in the customer's domain. One potential realization of IMS Residential 
Gateway is presented in figure 15. 
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Figure 15: Potential realization of NGN IMS Residential Gateway 

The ISIM within the IRG represents the required security functionality for IMS in NGN. In NGN Rl, the ISIM [18] 
shall be deployed in conjunction with a UICC [14], [15], [16], [17]. 

The operator shall disable all implicit registrations sets from the HSS, on behalf of those ISIMs that are dedicated to 
IMS Residential Gateways. If there are implicit registrations sets defined in the HSS, then the implementation of IMS 
Residential Gateway gets a lot harder. It is recommended that the ISIM include only one Public User Identity. 

IMS Residential Gateway when implemented in a device should be robust, and therefore it should store the registrations 
states (local and IMS registration states) and security connections states to a memory that is not erased during outages. 
It is recommended that the IMS Residential Gateway and the local UAs authenticate each other, and communicate using 
some security mechanism. The content of these security measures are out of the scope of the present document. 

If the IMS Residential Gateway has phone capabilities by itself, then that phone should be treated like any other local 
phone. 

NOTE 1: A typical IMS Residential Gateway would work as follows. When the IMS Residential Gateway device is 
switched on, and the first local UA is registered, then the IMS Residential Gateway registers the IMS 
Residential Gateway identity. The gateway identity is one of the public user identities that are stored to 
the ISIM. IMS Residential Gateway gets all the associated URIs from P-Associated-URI header field 
during the registration of explicit line identity. Then the IMS Residential Gateway continues processing 
the local registration request, assuming that the local registration request is related to one of the associated 
Public User Identities. After these steps the IMS Residential Gateway should monitor the registration 
state by subscribing to the registration event package in S-CSCF. Subsequent local registration requests 
do not initiate the registration of explicit line identity. The incoming calls that are directed to the IMS 
Residential Gateway identity are automatically directed to all connected UAs. Personal identities are 
always explicitly registered, and incoming calls to them are always directed only to associated UAs. 

NOTE 2: Devices that have an ISIM do not have to use IMS Residential Gateway. 
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NOTE 3: How to secure the link(s) between UE and IRG is outside the scope of the present document. 
Annex B includes some informative implementation notes on the IMS Residential Gateway. 
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Annex A (informative): 
NGN-relevant security interfaces: 



This clause identifies the security interfaces that are relevant in NGN. This annex extracts relevant material from other 
NGN specifications. 



A.1 Network attachment security interfaces 

The Network Attachment Subsystem provides the following security functionalities; see [6], clause 4.1: 

• User authentication taking place prior or during the IP address allocation procedure. 

• Authorization of network access based on user profiles. 

The Network Attachment Subsystem (NASS) comprises the following security related functional entities that are 
relevant for Access Domain Security: 

• Customer Network Gateway (CNG) requests access from the network. 

• The Access Management Function (AMF) (see [6], clause 5.2.2) forwards requests to the User Access 
Authorization Function (UAAF) to authenticate the user, authorize or deny the network access, and retrieve 
user-specific access configuration parameters. 

In case PPP is applied, the AMF terminates the PPP connection and provides the inter-working with the 
reference point to the network attachment subsystem e.g. using an AAA protocol (RADIUS or Diameter). The 
AMF acts as a RADIUS client if the UAAF is implemented in a RADIUS server (the AMF terminates the PPP 
and translates it to signalling on the a3 reference point). 

• User Access Authorization Function (UAAF) (see [6], clause 5.2.4) performs user authentication, as well as 
authorization checking, based on user profiles, for network access. For each user, the UAAF retrieves 
authentication data and access authorization information from the user network profile contained in the Profile 
Data Base Function (PDBF). The UAAF also collects accounting data for the changing of the service usage. 
The User Access Authorization Function (UAAF) acting as proxy can locate and communicate with the UAAF 
acting as server which can visit the PDBF user authentication data stored in, and forward access and 
authorization requests, as well as accounting messages, received from the AMF, to the UAAF acting as server. 
Responses received back in return from the UAAF acting as server will be forwarded to the AMF. 

• The Profile Database Function (PDBF) (see [6], clause 5.2.5) is the functional entity that contains user 
authentication data (e.g. user identity, list of supported authentication methods, authentication keys...) and 
information related to the required network access configuration: these data are called "user network profile". 
In this release the reference point between UAAF and PDBF is not specified, i.e. UAAF and PDBF are either 
collocated or connected by a non-standardized interface. 

The PDBF can be co-located with the UPSF (described in [3]) where this makes sense in the context on the 
business models being supported (e.g. if the same provider operates both the IP connectivity services and the 
IMS services). 

Figure A. 1 provides an overview of the relationships between these functional entities and related reference points. 
Further details about these and other NASS functionalities and the complete NASS architecture can be found in [6], 
clause 5.1. 
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NOTE: UAAF and PDBF are either co-located, or an interface exists among both FEs. This interface is not 
specified in NGN Release 1 and is left as for further study. 

Figure A.1 : NASS functions involved with secure networl< attachment [6] 

A.1 .1 Reference Point e1 (CNG - AMF) 

This reference point enables the user equipment to provide user credentials (password, token, certificate, etc.) to the 
Network Attachment Subsystem (NASS) in order to perform network access authentication. This reference point may 
also enable the NASS to provide authentication parameter to the UE to perform the network authentication when mutual 
authentication procedure is required. Based on the authentication result, the NASS authorizes or denies the network 
access to the user equipment; see also [6], clause 5.5.2. 

A.1 .2 Reference Point e2 (CLF - AF) 

This reference point enables applications and service control subsystems to retrieve from the CLF network location 
information. The primary parameter to retrieve the location information shall be the Assigned IP address allocated to 
the UE; see also [6], clause 5.5.1. 

The form of location information that is provided by the CLF depends on the requestor. 

The following information flows are used on the CLF to AF reference point: 

• Location Information Query. 

• Location Information Response. 

A.1 .3 Reference Point a3 (AIVIF - UAAF) 

This reference point allows the AMF to request the UAAF for user authentication and network subscription checking; 
see also [6], clause 5.5.3. 

A.1 .4 Reference Point e5 (UAAF - UAAF) 

This reference point is intended to be used by a UAAF proxy and a UAAF server, which may be in different 
administrative domains. This reference point allows the UAAF-proxy to request the UAAF-server for user 
authentication and authorization, based on user profiles. It also allows the UAAF-proxy to forward accounting data for 
the particular user session to the UAAF-server; see also [6], clause 5.3.6. 
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The UAAF-proxy will forward access and authorization requests, as well as accounting messages, received over 
reference point a3 from the AMF, to the UAAF-server over reference point e5. Responses received back in return from 
the UAAF-server over interface e5 will be forwarded to the AMF over reference point a3. A bilateral trust relationship 
will need to be setup between the UAAF-proxy and the UAAF-server in order to facilitate this exchange. 

This reference point therefore supports AAA message exchange between the UAAF-proxy and the UAAF-server. 
RADIUS and Diameter are two possible options for carrier protocols on this reference point. 



A.2. Service layer security interfaces 
A.2.1 NGN IP Multimedia Subsystem (IMS) 

The IP Multimedia Subsystem (IMS) core component of the NGN architecture (Core IMS) supports the provision of 
SIP-based multimedia services to NGN terminals. It also supports the provision of PSTN/ISDN simulation services. 

The architecture of this subsystem is further described in [4]. Figure A. 2 provides an overview of the architecture, 
interfaces related to Access Security Domain are marked by dashed line. 



Network 
Attachment 
Subsystem 




IP Transport (Access and Core) 



Figure A.2: NGN IMS architecture - Access security [4] 

A.2.1 .1 Reference Point Gm (UE/IMS Residential Gateway - P-CSCF) 

The Gm reference point supports secure communication between an UE or an IMS Residential Gateway and the IMS, 
e.g. related to registration and session control; see [27], clause 9.2. Security set-up shall be possible using an ISIM 
application [18]. 

The security association between UE or IMS Residential Gateway and P-CSCF is established during IMS registration 
procedure. All subsequent session control messages will use this security association. 

NOTE 1: Exact security mechanism for Gm interface is FFS. 

NOTE 2: According to TS 181 005 (see bibliography), early implementations may use the so-called "line 
authentication" mechanism. This mechanism is optional for implementation. 

An interface between the UE and the IMS Residential Gateway is considered outside the scope of the present document. 
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A.2.1 .2 Reference Point Cx (CSCF - UPSF) 

The Cx reference point supports information transfer between CSCF and UPSF. Further information on the Cx 
reference point is provided in [27], clause 9.3.2. The following security related procedures are supported: 

1) Procedures related to authorization (e.g. checking of roaming agreement). 

2) Procedures related to authentication: transfer of security parameters of the subscriber between UPSF and 
CSCF. 

Cx reference point shall support IMS AKA as mandatory authentication mechanism. 

A.2.1 .3 Reference Point Gq' (P-CSCF - RACS) 

The Gq' reference point is used by P-CSCF to reserve resources from the transport layer; see [27], clause 5.3.2. 
Important security functionality is related to traffic filtering. C-BGF filters unauthorized media streams, i.e. it only 
passes media packets through if P-CSCF has authorized them. P-CSCF uses the content of SDP payload of existing SIP 
sessions when making the authorization decisions. 

A.2.1 .4 Reference Point Iw (IWF - non-compatible SIP) 

Interconnection with external networks supporting a non-compatible version of SIP is performed at the Iw reference 
point, via the IWF, see [27]. This interface may support TLS as specified in [9]. 

A.2.1 .5 Reference Point Ic (IBCF - IMS) 

IP-based interconnection with external networks supporting IMS is performed at the Ic reference point, via the IBCF; 
see [27], [28]. Ic interface is protected using 3GPP Network Domain Security as specified in [9]. 

Network Domain Security refers to security within a NGN operator domain and between NGN operator domains that 
have a fixed roaming agreement. NGN Domains are networks that are managed by a single administrative authority. 
The same level of security and usage of security services will be typical within a NGN Domain. A network operated by 
a single operator will typically constitute one NGN Domain although an operator may subsection its network into 
separate sub-networks. 

A.2.1 .6 Reference Point Id (IBCF - l-BGF) 

Id interface is used by IBCF to reserve resources from the transport layer. Important security functionality is related to 
traffic filtering. I-BGF filters unauthorized media streams, i.e. it only passes media packets through if IBCF has 
authorized them. IBCF uses the content of SDP payload of existing SIP sessions when making the authorization 
decisions. 

Id reference point is seen as internal interface in the operator network. Network configuration shall take care that this 
interface is not accessible outside the trust domain. 

A.2.1 .7 Reference Point Ut (UE - AS) 

his interface enables the user to manage information related to his services, such as creation and assignment of Public 
Service Identities, management of authorization policies that are used e.g. by Presence service, conference policy 
management, etc. 

[7] defines the Ut interface between a UE and an AS for the purpose of manipulating user controlled setting and 
variables at the AS; see figure A.3. 



UE 



Ut 



AS 



Figure A.3: Ut interface 
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Ut interface is protected with TLS. Authentication may be based on the Generic Authentication Architecture (GAA) as 
defined in [12] or the HTTP Digest mechanisms defined [39]. 



A.3 Interconnection security interfaces 

NGN may interconnect with several types of networks, e.g. at the service layer with SS7-based networks or IP-based 
networks, and at the transfer level with TDM-based or with IP-based networks. Interconnection may take place within 
the NGN trust domain, or between NGN and non-NGN trust domains. More details of NGN Release 1 interconnections 
are available in [3] and in [27], Figure A.4 represents IP-based interconnection. 
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Figure A.4: IP Interconnection [3] 

Figure A.5 illustrates the case where no I-BGF is inserted. Figure A. 6 illustrates the case where an I-BGF is inserted by 
the visited network; see also [27]. 
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Figure A.5: IMS interconnect scenario without I-BGF [27] 
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NOTE: As a network operator's option, an l-GSGF with encryption-based topology hiding capabilities (THIG) may 
also be inserted in the IMS before the IBCF. This is not represented on the above figures. 

Figure A.6: IMS interconnect scenario with l-BGF [27] 

[28] describes further interconnect scenarios showing usage of the optional IBCF. 

A.3.1 Interconnecting security at the transport layer 

Iz interface is used by IBCF to reserve resources from the transport layer. Important security functionality is related to 
firewall control. I-BGF act as the so-called "pinhole firewall" for media streams, i.e. it only passes media packets 
through if IBCF has authorized them. IBCF uses the content of SDP payload of existing SIP sessions when making the 
authorization decisions. 

Iz reference point is seen as internal interface in the operator network. Network configuration shall take care that this 
interface is not accessible outside the trust domain. 

A.3.2 Interconnecting security at the service layer 

Security measures when interconnecting with SS7 networks are out of the scope of the present document. 
IP-based interconnection with external networks supporting is performed at the Ic reference point, via the IBCF. 



£75/ 



40 ETSI TS 187 003 V1 .1 .1 (2006-03) 



Annex B (informative): 

Mapping of NGN R1 Security Requirements to Security 

Services 

Table B.l identifies which security functions (AUTH, AUTHOR, KM, CONF, INT, PEF) are required in the NGN Rl 
security architecture to fulfil the NGN Rl security requirements [1]. 
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Table B.1 : Mapping of NGN-R1 requirements to security functions 



Requirement 
Reference 


Statement of Requirement 


Specific Security Function 
required ? 


Security Functional 
Element 


Security Policy Requirements 


R-SP-1 


The NGN network shall be logically and physically divided into security domains allowing for 
separation of application (e.g. IMS) and transport (e.g. ADSL or UMTS). Also different 
operators of similar networks (e.g. IMS) shall be able to operate their own security policies. 


No 

NOTE: The split is a mandate 
of the regulatory regime but of 
itself does not require security 
functional entities, however at 
deployment the logical and 
physical separation requires 
that at the FE level some 
consideration has to be made 
for the existence of relay or 
proxy functions. 




R-SP-2 


Security mechanisms and other parameters beyond default security mechanisms shall be 
configurable. This shall be static for NNI interface and may be negotiated for UNI interfaces. 
The security mechanism negotiation shall have a certain minimum level to be defined by the 
security domain; e.g. avoid bidding-down attacks. Users shall be able to reject 
communications that do not conform to their minimum security policy. 


No 




R-SP-3 


The security mechanisms shall be partitioned such that the functions of authentication, data 
integrity, replay detection, and confidentiality may be implemented and selected independently 
of each other, insofar as this makes sense. 


No 




R-SP-4 


The UE shall always offer encryption algorithms for P-CSCF to be used for the session and 
the P-CSCF policy shall define whether to use encryption or not. 


No 

NOTE: The detail definition of 
the UE is considered out of 
scope of NGN. However for 
confidentiality functions the 
configuration protocol should 
be capable of algorithm 
selection. 




R-SP-5 


UE and the P CSCF shall negotiate the integrity algorithm that shall be used for the session. 


Yes 


KM 


R-SP-6 


The policy of the HN shall be used to decide if an authentication shall take place for the 
registration of different IMPUs e.g. belonging to same or different service profiles. 


Yes 


PEF, AUTH 


R-SP-7 


The security gateway functions (SEGF) shall be responsible for enforcing security policies for 
the interworking between networks. 

NOTE: The actual inter-security domain policy is not standardized and is left to the discretion 
of the roaming agreements of the operators. 


Yes 


PEF 


R-SP-8 


SEGFs are responsible for security sensitive operations and shall offer capabilities for secure 
storage of long-term keys used for IKE authentication. 


Yes 


SEGF, AUTH 


Authentication, Authorization, Access Control and Accountability Requirements 


R-AA-1 


Access to NGN networks, services, and applications shall be provided for authorized users 
only. 


Yes 


PEF, AUTHORF 


R-AA-2 


NGN R1 IMS authentication shall support early deployment scenarios (with support for legacy 
equipments). 


No 
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Requirement 
Reference 


Statement of Requirement 


Specific Security Function 
required ? 


Security Functional 
Element 


R-AA-3 


In non-early deployment scenarios, IMS authentication shall be independent from access 
authentication. 


No 




R-AA-4 


An ISIM shall be used to access any IMS service, however, exceptions may be allowed for 
emergency calls and early deployment scenarios. 


No. Insofar as ISIM is not 
detectable at the interface 
between UE and NGN. 
NOTE: In the provision phase 
rather than in the activation 
phase the role of ISIM is 
clearer. 




R-AA-5 


ISIM based Authentication between the IMS-subscriber and the network shall comply to the 
authentication part of Access Security for IP-based services [8]. 


No 




R-AA-6 


ISIM based Re-authentication of an IMS-subscriber shall comply to the authentication part of 
Access Security for IP-based services [8]. 


No 




R-AA-7 


It shall be possible to prevent the use of a particular ISIM to access NGN networks and 
services and it should be possible to revoke a specific ISIM. 


Yes 


PEF 


R-AA-8 


NGN relevant ISIM specific information shall be protected against unauthorized access or 
alteration. 


No 




R-AA-9 


User authentication may either be hardware-based (for 3GPP UE: ISIM; i.e. proof by 
possession of a physical token) or be software-based (i.e. proof by knowledge of some secret 
information). 


No 




R-AA-10 


User Authentication to the NGN IMS using SIP Digest mechanisms shall be supported as a 
early deployment scenario. 


Yes 


AUTH 


R-AA-1 1 


Where both Digest and ISIM solutions are deployed by an NGN IMS operator, that operator 
shall determine the authentication mechanism (SIP Digest or ISIM-based) on a per-user basis. 
The authentication mechanism shall be enforced according to both the subscription 
information in the user's service profile and the specific policies of the NGN IMS operator. 


Yes 


PEF 


R-AA-12 


Transmitted passwords shall be sufficiently protected; e.g. by encryption or other techniques. 


Yes 


CONF, INTF 


R-AA-1 3 


For the special early deployment scenarios (see note 1), where IMS authentication is linked to 
access authentication, it shall be possible to gain access to IMS services after an 
authentication procedure. This authentication provides simultaneous access to the access 
network and IMS services. 
NOTE 1 : The two special early deployment scenarios are (also refered to as NASS Bundled 

authentication): 

(A). IMS authentication is linked to access line authentication (no nomadicity) 

(B). IMS authentication is linked to access authentication for IP Connectivity (limited 

nomadicity can be provided). 
NOTE 2: Access authentication may result in IMS services being tied to the access point 

(line) or to the current IP Connectivity (device). In the latter case limited nomadicity 

may be available. No IMS specific authentication is therefore required from the 

CPE/Terminal to gain access to IMS services. 


Yes 


AUTH 


R-AA-1 4 


The NGN subsystems shall be able to define and enforce policy with respect to validity of user 
authorization. 


Yes 


PEF 


R-AA-1 5 


Mutual authentication shall be supported between the UE and the AS before providing 
authorization. 


Yes 


AUTH, AUTHOR 
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Requirement 
Reference 


Statement of Requirement 


Specific Security Function 
required ? 


Security Functional 
Element 


R-AA-16 


It SHOULD also be possible to support an Authentication Proxy based architecture. 

NOTE: The purpose of the AP is to separate the authentication procedure and the AS specific 

application logic to different logical entities. 


Yes 


AUTH 


R-AA-17 


Mutual authentication shall be supported between the UE and the AP. 


Yes 


AUTH 


R-AA-18 


The AP shall decide whether a particular subscriber (i.e. the UE), is authorized to access a 
particular AS. 


Yes 


AUTHOR 


R-AA-19 


If an AP is used, the AS shall only authorize the access request to the requested resource. 
NOTE: The AS does not need to explicitly authenticate the user. 


Yes 


AUTHOR 


R-AA-20 


Mutual authentication should be supported between the UE and the MASS during access 
network level registration. 


Yes 


AUTH 


R-AA-21 


The access network shall be able to authenticate and authorize the access subscriber. 


Yes 


AUTH, AUTHOR 


R-AA-22 


Authentication and authorization to the Access Network is controlled by the operator of the 
Access Network. 


Yes 


AUTH, AUTHOR, 
PEF 


R-AA-23 


The attributes required for authentication of a user by the access network maybe provided by 
the network operator to whom the user has a NGN IMS subscription. 


Yes 


AUTHOR 


R-AA-24 


NASS shall support both the use explicit (e.g. PPP or IEEE 802. 1x [45]) and/or implicit line 
authentication (e.g. MAC address authentication or line authentication) of the 
users/subscribers. In the case of the implicit access authentication, it shall rely only on an 
implicit authentication through physical or logic identity on the layer 2 (L2) transport layer. 


Yes 


AUTH 


R-AA-25 


In case the CNG is a routing modem and the Customer Premises Network (CPN) is a private 
IP realm, authentication shall be initiated from the CNG. 


Yes 


AUTH, PEF 


R-AA-26 


In case the CNG is a bridge, each UE shall authenticate with the NASS as the IP realm in the 
CPN is known to the Access Network. 


Yes 


AUTH 


R-AA-27 


As the interface between the Application Function (AF) and RACS can be inter-operator, the 
RACS shall authenticate and authorize the Application Function (AF). 


Yes 


AUTH, AUTHOR 


R-AA-28 


A media gateway controller must be able to handle authentication of multiple media gateways, 
i.e. to maintain multiple security associations with different media gateways. 


Yes 


AUTH 


R-AA-29 


Authentication of NGN users and authentication of NGN terminals shall be separate. 


No 




R-AA-30 


Caller id and location information shall be stored according to the Common European 
regulatory framework by the EMTEL Service Provider. Caller ID and location information shall 
be validated by the EMTEL Service Provider. 


No 




Identity and Secure Registration Requirements 


R-IR-1 


It shall be possible to implicitly register IMPU(s). The implicitly registered IMPU(s) all belong to 
the same Service Profile. All the IMPU(s) being implicitly registered shall be delivered by the 
HSS to the S-CSCF and subsequently to the P-CSCF. The S-CSCF shall regard all implicitly 
registered IMPU(s) as registered IMPU(s). 


No 




R-IR-2 


An access identity shall be used for access authentication. This identity may or may not be 
used for other purposes. 


No 
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Requirement 
Reference 


Statement of Requirement 


Specific Security Function 
required ? 


Security Functional 
Element 


R-IR-3 


The line ID shall be possible to use for line authentication. 


No 

NOTE: Identity and the 

association of identity to 

service does not imply an FE 

but may imply an information 

element within an information 

flow. 




Communications and Data Security Requirements 


R-CD-1 


Confidentiality and integrity of IMS signalling shall be applied in a hop-to-hop fashion. 
(UE-to-P-CSCF and among other NEs). 


Yes 


CONF, INTF 


R-CD-2 


Network Domain Security (NDS) shall be provided at the network layer and comply to [9]. 


Yes 


SEGF(AUTH, 
AUTHOR, KM, 
CONF, INT, PEF) 


R-CD-3 


All NDS/IP traffic shall pass through a SEGF (Security Gateway Function) before entering or 
leaving the security domain. IMS operators shall operate NDS/IP Za interface between SEGFs 
according to [9]. 


Yes 


SEGF(AUTH, 
AUTHOR, KM, 
CONF, INT, PEF) 


R-CD-4 


Security shall be provided within the network domain for the Cx interface. 


Yes 


SEGF(AUTH, 
AUTHOR, KM, 
CONF, INT, PEF) 


R-CD-5 


An ISIM based solution for IMS access security (authentication, confidentiality and integrity 
protection) of signalling to and from the user, shall be supported. 


Yes 


AUTH, INT, CONF 


R-CD-6 


Secure link shall be provided between UE and the P-CSCF for protection of the Gm reference 
point. 


Yes 


AUTH, AUTHOR, 
CONF, INT 


R-CD-7 


In case access authentication is independent from IMS authentication: 

• Solutions for access to the NGN core shall provide for secure transfer of signalling to 
the NGN core independent of the access technology. 

• Solutions for access to the NGN core shall provide for secure transfer of signalling to 
the NGN core independent of the presence of intermediate IP networks connecting 
the NGN access with the NGN core. 

• Solutions for access to the NGN core shall allow for mutual authentication of end 
user and NGN core. It shall be possible for the terminal to authenticate the user. 


Yes 


CONF, INT, AUTH, 
AUTHOR 


R-CD-8 


In the case where IMS authentication is linked to access line authentication the underlying 
access technology shall provide protection of NGN signalling and user data. 


No 




R-CD-9 


ISIM specific information shall be updated in a secure manner. 


No 




R-CD-1 


It shall be possible to protect sensitive data (such as Presence information and notifications) 
from attacks (e.g. eavesdropping, tampering, and replay attacks). 


Yes 


CONF, INT, AUTH, 
AUTHOR 


R-CD-1 1 


The Rq and Gq' reference points shall provide mechanism to assure security of the 
information exchanged. 


Yes 


SEGF(AUTH, 
AUTHOR, KM, 
CONF, INT, PEF) 


R-CD-1 2 


All data related to configuring the UE through the e3 if shall be protected against loss of 
confidentiality and against loss of integrity. 


Yes 


AUTH, AUTHOR, 
KM, CONF, INT, 
PEF 


Integrity and Replay Protection Requirements 
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Requirement 
Reference 


Statement of Requirement 


Specific Security Function 
required ? 


Security Functional 
Element 


R-CD-13 


Integrity protection of signalling, control communications and of stored data shall be provided. 


Yes 


INT, AUTH, 
AUTHOR 


R-CD-14 


It shall be possible to ensure the origin, integrity and freshness of authentication data, 
particularly of the cipher key. 


Yes 


INT, AUTH, 
AUTHOR 


R-CD-15 


Integrity protection shall be applied between the UE and the P-CSCF for protecting the SIP 
signalling. 


Yes 


INT, AUTH, 
AUTHOR 


R-CD-16 


Integrity protection between Network Elements (e.g. between CSCFs, and between CSCFs 
and the HSS) shall rely on mechanisms specified by Network Domain Security in [9]. 


Yes 


SEGF(AUTH, 
AUTHOR, KM, 
CONF, INT, PEF) 


R-CD-17 


Data integrity shall be supported between the UE and the Application Server. 


Yes 


INT, AUTH, 
AUTHOR 


Confidentiality Requirements 




R-CD-18 


Confidentiality of communications should be achieved by cryptographic encryption. 
Confidentiality of stored data shall be achieved by cryptographic encryption or by access 
controls. 


Yes 


CONF 


R-CD-19 


Confidentiality of signalling and control messages shall be enforced if required by the 
application or in environments where the security policy demands confidentiality. The 
mechanism should allow a choice in the algorithm to be used. 


Yes 


CONF 


R-CD-20 


IMS specific confidentiality protection shall be provided for the SIP signalling between UE and 
P-CSCF. 


Yes 


CONF 


R-CD-21 


Confidentiality protection between Network Functions (e.g. between CSCFs, or between 
CSCFs and the HSS) shall rely on mechanisms specified by Network Domain Security in [9]. 


Yes 


SEGF(AUTH, 
AUTHOR, KM, 
CONF, INT, PEF) 


R-CD-22 


It shall be possible to protect the confidentiality of user-related data which is stored or 
processed by a provider. 


Yes 


CONF 


Privacy Requirements 




R-P-1 


It shall be possible to protect the network topology from exposure toward other domains. It 
shall also be possible for a security domains to define and implement protection against traffic 
analysis for signalling and management protocols. 


Yes 


PEF 


R-P-2 


User location and usage patterns shall be kept from unwanted disclosure. 


Yes 


PEF 


R-P-3 


It shall be possible to protect the confidentiality of user identity data. 


Yes 


CONF 


R-P-4 


Anonymous communication sessions shall be supported in NGN either in a permanent mode 
or in a temporary mode communication by call. In this case the originating party identity shall 
not be presented to the destination party. The network to which the destination party is 
connected to is responsible to handle this service. 


Yes 


PEF 


R-P-5 


NGN shall support the specific case where the destination party has an override right (e.g. 
emergency communication sessions), and the originating party identity is provided to the 
destination party independent whether or not this communication session is anonymous. 


Yes 


PEF 


R-P-6 


The Anonymous Communications Rejection (ACR) simulation service shall allow the served 
user to reject incoming communication from users or subscribers who have restricted the 
presentation of their originating identity according to the OIR simulation service. 


Yes 


PEF 
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Requirement 
Reference 


Statement of Requirement 


Specific Security Function 
required ? 


Security Functional 
Element 


R-P-7 


The NGN shall support mechanisms for the network operator to guarantee the authenticity of 
a user identity presented for an incoming call to a user where the call is wholly within that 
operator's network (i.e. originating and terminating parties are subscribers to, and resident in, 
a single NGN). 


Yes 


PEF, AUTH 


R-P-8 


The NGN shall provide mechanisms that allow to present the identity of the session originator, 
if this is not restricted by the session originator. 


Yes 


PEF 


R-P-9 


The privacy aspect of presence information and the need for authorization before providing 
presence information shall be configurable by the user (i.e. presentativity). 


No 




R-P-10 


A principal of a presentativity shall, at any time, be able to control to whom, for how long and 
what (all or part of) presence information of the presentativity is provided, and a principal of a 
watcher shall, at any time, be able to control to whom, for how long and what (all or part of) 
watcher information of the watcher is provided. 


Yes 


PEF, AUTHOR 


R-P-11 


Any services using the presence information shall ensure privacy agreement before releasing 
presence information. The presence service does not address deployment specific issues 
(e.g. where agreements are stored or how they are negotiated). It only gives requirements for 
privacy management. 


Yes 


PEF 


R-P-12 


It shall be possible for the sender of the message to request to hide its public ID from the 
recipient. 


No 




R-P-13 


Users may select the Identity presented when starting a session or sending a message. It 
shall be possible to verify this identity and to initiate a session or message in reply. 






Key Management Requirements 




R-KM-1 


Key management and key distribution between SEGFs shall comply to the Network Domain 
Security [9]. 


Yes 


KM 


R-KM-2 


The UE and the AS shall be able to resume a previously established secure session. 


Yes 


KM 


R-KM-3 


The key management mechanism must be able to traverse a NAT/NATP device. 


Yes 


KM 


NAT/Firewall lnterworl<ing Requirements 


R-NF-1 


NGN security protocols shall work with commonly-used firewalls and shall work in 
environments with NAT/NATP. 


No 




R-NF-2 


Filters to screen the IP packets to restrict/grant access to specific bearer streams shall be 
supported. 


Yes 


PEF 


R-NF-3 


The SEGFs may include filtering policies and firewall functionality not required in [9]. 


Yes 


PEF 


Availability and DoS protection Requirements 


R-AD-1 


Mechanisms shall be provided to mitigate denial-of-service attacks. 


No 




R-AD-2 


Provide access control mechanisms to ensure that authorized users only can access the 
service. 


Yes 


AUTHOR, PEF 


R-AD-3 


It shall be possible to prevent intruders from restricting the availability of services by logical 
means. 


Yes 


AUTHOR, PEF 


R-AD-4 


Availability of and accuracy of location information shall be provided for the EMTEL services. 


No 




R-AD-5 


Availability of EMTEL PSAPs shall not be decreased by DoS attacks. EMTEL PSAPs shall be 
able to reconnect. 


No 




Assurance Requirements 


R-AS-1 The NGN shall provide guidance for evaluating and certifying NGN equipment and systems. No 
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Requirement 
Reference 


Statement of Requirement 


Specific Security Function 
required ? 


Security Functional 
Element 


R-AS-2 


Security implications of potential misuse of protocols used in NGN shall be documented 
through a TVRA. This enables users to assess the security they need before deploying the 
given protocol. 


No 




Requirements on Strength of Security Mechanisms 


R-SS-1 


The guidelines defined in ES 202 238 [44] shall be followed when defining or selecting 
cryptographic algorithms in NGN. 


No 
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Annex C (informative): 

Implementation notes on the IIVIS Residential Gateway 

The following use cases describe how a non-ISIM SIP User Agent (UA) can register and establish calls via the SIP 
B2BUA within an IMS Residential Gateway. The use cases are based on [7]. The different parts are how the UA is 
connected and how the SIP B2BUA maps the identities and the messages. 

It must be noted, that the operator must not define any implicit registration sets in HSS, on behalf of those ISIMs that 
are dedicated to B2BUAs. 



C.1 B2BUA registration 



The I-CSCF has been excluded in the use case just for simplification. It is still there in the real use case. 
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Figure C.1 : IMS Residential Gateway registration message flow 
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1) The UAl registers to the SIP B2BUA with a To header including a local username (bob) that is associated to 
the subscription for the ISIM. 

example message: 
REGISTER To: <sip:bob> 

2) The B2BUA optionally challenges the user. The subscriber can for example locally configure if local users 
should be challenged and the passwords to use for the local users. 

Example message: 

401 WWW-Authenticate Digest 

3) The UAl resends the register message if challenged. The message then contains an Authorization header 
including the identity (bob) of the challenged user included in the username parameter. 

Example message: 

REGISTER Authorization Digest username=bob 

4) The B2BUA use the Private User Identity stored in the ISIM as the username. The Contact header contains the 
IP address (or domain name) of the B2BUA. The selected Public User Identity in the To header is the value in 
the To header from the UAl or a mapped name (bob.smith@operator.net) where a local username used by the 
UAl is mapped to a Public User Identity. The subscriber can locally configure this mapping. 

Example message: 

REGISTER Authorization Digest username=IMPI, Security-Client To:<sip:bob.smith@>operator.net> 

5) The P-CSCF sends the request to the S-CSCF after excluding some headers (Proxy-Require and 
Security-Client) and some header information (e.g. sec-agree from the Require header). 
Example message: 

REGISTER Authorization Digest username=IMPI 
To:<sip:bob.smith@>operator.net> 

6) The S-CSCF request authentication vectors from HSS in case the client must be authenticated and there are no 
authentication vectors. The client must initially be authenticated (indicated e.g. by the lack of a downloaded 
service profile). 

Example message: 
Diameter MAR 

7) The HSS then returns one or several authentication vectors. 
Example message: 

Diameter MAA 

8) The S-CSCF challenges the B2BUA/ISIM with a 401 including RAND and AUTN in case chent 
authentication is necessary. 

Example message: 

401 www-Authenticate (RAND, AUTN) 

9) The P-CSCF adds some headers to the 401 before sending it to the B2BUA. 
Example message: 

401 WWW -Authenticate (RAND, AUTN) Security-Server 

10) The B2BUA calculates a RES and verifies the AUTN if challenged by a 401 . The B2BUA then sends a new 
REGISTER including an Authorization header with the digest where RES has been used as the shared key. 
Example message: 

REGISTER Authorization username=IMPI, RES Security-Client, Security- Verify 
To:<sip:bob.smith@>operator.net> 

1 1) The P-CSCF sends the request to the S-CSCF after excluding some headers (Proxy-Require, Security- Verify 
and Security-Client) and some header information (e.g. sec-agree from the Require header). The S-CSCF 
verifies the digest based on RES from the B2BUA with the digest calculated with XRES. This is only 
necessary if the B2BUA has been challenged. 

Example message: 

REGISTER Authorization Username=IMPI, RES 

To:<sip:bob.smith@>operator.net> 

12) The S-CSCF responds with a 200 including Path, Service-Route and P-Associated-URI headers. 
Example message: 

200 Path Service-Route P-Associated-URI 
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13) The B2BUA stores the content of the Service-Route and P-Associated-URI headers and then removes the Path, 
Service-Route and P-Associated-URI headers before sending a 200 to the UAl. 

Example message: 
200 

14) The UA2 registers to the SIP B2BUA with a To header including a local username (alice) that is associated to 
the subscription for the ISIM. 

Example message: 
REGISTER To: <sip:ahce> 

15) The B2BUA optionally challenges the user. 
Example message: 

401 www-Authenticate Digest 

16) The UA2 resends the register message if challenged. The message then contains an Authorization header 
including the identity (alice) of the challenged user included in the username parameter. 

Example message: 

REGISTER Authorization Digest username=alice 

17) The B2BUA use the Private User Identity stored in the ISlM as the username. The selected Public User 
Identity in the To header is the mapped name (alice.smith@operator.net). 

Example message: 

REGISTER Authorization username=IMPI, Security-Client Security- Verify 

To:<sip:alice.smith@operator.net> 

18) The P-CSCF sends the request to the S-CSCF after excluding some headers (Proxy-Require, Security-Verify 
and Security-Client) and some header information (e.g. sec-agree from the Require header). 

Example message: 

REGISTER Authorization: username=IMPI, 

To : <sip : alice .smith @ operator.net> 

19) Since the S-CSCF has already authenticated the Private User Identity (there is a service context) there is no 
need to do it again. The S-CSCF responds with a 200 including Path, Service-Route and P-Associated-URI 
headers. 

Example message: 

200 Path Service-Route P-Associated-URI 

20) The B2BUA stores the content of the Service-Route and P-Associated-URI headers and then removes the Path, 
Service-Route and P-Associated-URI headers before sending a 200 to the UAl. 

Example message: 
200 
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C.2 B2BUA originating session establishment 
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Figure C.2: B2BUA originating session establishment message flow 

1) The UAl sends an INVITE to the B2BUA: 
Example message: 

INVITE sip:carl.jones@otheroper.net Contact <sip:192.168.1.2> From; <sip:bob> 

2) The B2BUA responds with a 100 Trying. 

3) The B2BUA adds some headers to the INVITE message. The From header is converted to the Public User 
Identity that is equal to the personal identity for the user. The P-Preferred-Identity header contains as well the 
personal identity. The B2BUA changes the Contact header and sends the INVITE to the P-CSCF. 
Example message: 

INVITE sip:carl.jones@otheroper.net Contact <sip:130.1.2.3 :5678> 
From:<sip:bob.smith@operator.net> 

4) The P-CSCF responds with 100 Trying. 
Example message: 

100 Trying 

5) The P-CSCF removes the P-Preferred-Identity and inserts instead a P-Asserted-Identity that contains the 
content of P-Preferred-Identity if that was authorized from the network point of view. The P-CSCF then sends 
the INVITE to the S-CSCF. 

Example message: 

INVITE sip:carl.jones@otheroper.net Contact <sip: 130.1.2.3 :5678> 

From:<sip:bob.smith@operator.net> 

6) The S-CSCF responds with 100 Trying. 
Example message: 

100 Trying 
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7) The S-CSCF removes the P-Access-Network-Info before the INVITE is sent out from the network. 
Example message: 

INVITE sip:carl.jones@otheroper.net 
Contact <sip: 130.1.2.3 :5678> 
From:<sip:bob.smith@operator.net> 

8) A remote CSCF responds with 100 Trying. 
Example message: 

100 Trying 

9) The other party sends a 1 80 Ringing 
Example message: 

180 Ringing Record-Route 

10) The other party sends a 200 OK 
Example message: 

200 OK Record-Route SDP 

11) The UAl acknowledges the 200 OK with an ACK. 
Example message: 

ACK 



C.3 B2BUA terminating session establishment 

The I-CSCF and HSS are excluded for simplicity. The I-CSCF is the initial point of contact. 
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Figure C.3: B2BUA terminating session establishment message flow 
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1) The remote UA sends an INVITE to the S-CSCF. 
Example message: 

INVITE sip:bob. smith@operator.net 
Contact <sip:132.100.101. 102 :7654> 
From:<sip:carl.jones@otheroperator.net> 

2) The S-CSCF responds with 100 Trying. 
Example message: 

100 Trying 

3) The S-CSCF picks the contact address stored at registration and inserts it as the Request-URL The S-CSCF 
inserts the original Request-URI is inserted in the P-Called-Party-ID header and sends the INVITE to the 
P-CSCF. 

Example message: 
INVITE sip:130.1.2.3:5678 
Contact <sip: 132. 100. 101. 102 :7654> 
From:<sip:carl.jones@otheroperator.net> 

4) The P-CSCF responds with 100 Trying. 
Example message: 

100 Trying 

5) The P-CSCF removes the P-Charging- Vector and sends the INVITE to the B2BUA. 
Example message: 

INVITE sip: 130. 1.2.3 :5678 Contact <sip:132.100.101. 102 :7654> 
From:<sip:carl.jones@otheroperator.net> 

6) The B2BUA responds with 100 Trying. 
Example message: 

100 Trying 

7) The B2BUA uses the Request-URI in the received request to find the home user that has previously registered. 
The Request-URI is replaced with the locally stored contact address. The B2BUA sends the INVITE to the 
UAl. 

Example message: 

INVITE sip:192.168.1.2 Contact <sip:192.168.1.1> From:<sip:carl.jones@otheroperator.net> 

8) The UAl responds with 100 Trying. 
Example message: 

100 Trying 

9) The UAl responds with 180 Trying. 
Example message: 

180 Trying 

10) The remote UA sends an ACK to the UAl via the S-CSCF and P-CSCF. 
Example message: 

180 Ringing 
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Annex D (informative): 

Supplementary Information on NASS-IIVIS Bundled 

Authentication 

D.1 Flow Diagram for MASS Bundled Authentication 

This clause describes how clients authenticate to NASS and simultaneously also gain service layer authentication using 
the "single-sign-on" NASS bundled authentication. The sequence diagram is depicted in figure D.l. 

1) The UE gets network attachment after the authentication at the NASS level. The CLF in the NASS (network 
attachment subsystem) holds a binding between the IP address and the location information (contains the Line 
Identifier), which the user holds per the xDSL connectivity. The selection of the authentication (whether NBA 
is possible or not) is done at UPSF level on IMS-user basis. 

2) As the SIP REGISTER message reaches P-CSCF, the P-CSCF knows whether or not a security association is 
required at this point, based on: 

the SIP signalling; 

presence of local policies (such as network interface); 

L3/L2 address. 

During the SIP registration, the P-CSCF locates the CLF based on the UE's IP address or/and based on the 
information of the access network from which the P-CSCF receives the IP packet (P-CSCF may have several 
logical/physical interfaces toward different Access Networks). P-CSCF performs a "Location Information 
Query" towards the CLF over the e2 interface. The key for the query is the IP address used by the UE. 

3) The CLF sends the response to the P-CSCF including the location information of the UE. 

4) The P-CSCF appends the NASS location information to the SIP REGISTER message and forwards the 
REGISTER message to I-CSCF and eventually to S-CSCF. 

5) S-CSCF queries the UPSF over the Cx interface using MAR request. 

6) The UPSF returns a message with the location information of the user identified by the IMPI and IMPU (if 
NASS Bundling is preferred authentication scheme). 

7) S-CSCF finally authenticates by comparing the location info embedded in REGISTER message with location 
information received from the UPSF. If they match the user is successfully authenticated and 200 OK message 
is sent to the UE. 
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Figure D.1 : Flow Diagram for NASS Bundled Authentication (see [7]) 
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Annex E (informative): 
Open Issues in NGN Security 

The following open issues are identified and remain as for further study: 

1) ISIM chaining: Usage of ISIM in terminals connected through other ISIM-enabled entities (e.g. IRG). 

2) PES/H.248 security: Investigate the H.248 security in case the NGN Rl assumptions do not apply. 

3) Usage/licensing of 3GPP security algorithms in NGN context. 

4) How to secure the Ic IF? SEGFs could be one possibility; security functions (e.g. integrated SEGF) as part of 
the IBCF could be another possibility. The current text is not clear on this. 

5) Security aspects of Emergency Telecommunications are not addressed yet in the present document. 
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